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I. Real Party in Interest 

The real party in interest is Hewlett-Packard Development Company, LP, a 
limited partnership established under the laws of the State of Texas and having a 
principal place of business at 20555 S.H. 249 Houston, TX 77070, U.S.A. (hereinafter 
"HPDC"). HPDC is a Texas limited partnership and is a wholly-owned affiliate of 
Hewlett-Packard Company, a Delaware Corporation, headquartered in Palo Alto, CA. 
The general or managing partner of HPDC is HPQ Holdings, LLC. 

II. Related Appeals and Interferences 

There are no known related appeals or interferences that will affect or be affected 
by a decision in this Appeal. 

III. Status of Claims 

Claims 16-24 have been canceled leaving claims 1-15 and 25-34 remaining. 
Each of those claims stand finally rejected. No claims have been allowed. The final 
rejections of claims 1-15 and 25-34 are appealed. 

IV. Status of Amendments 

In an after-final Response filed November 30, 2007, Applicant attempted to 
amend claims 3 and 15. In a subsequent Response to Non-Compliant Amendment, 
Applicant attempted to amend claim 3, 14, and 15. None of those amendments were 
entered by the Examiner. 



2 



V. Summary of Claimed Subject Matter 

The claimed inventions are summarized below with reference numerals and 
references to the written description ("specification") and drawings. The subject matter 
described in the following appears in the original disclosure at least where indicated, 
and may further appear in other places within the original disclosure. 

Independent claim 1 describes a method for collecting data regarding network 
service operation. The method comprises a client sending a request to a network 
service. Applicant's specification, page 11, lines 19-20; Figure 3A, item 300. The 
method of claim 1 further comprises intercepting the request sent by the client directed 
to the network service. Applicant's specification, page 11, lines 22-23; Figure 3A, item 
304. The method of claim 1 further comprises storing in a session timing profile 
information about the request including a name of the client, a name of the network 
service, and a request sent time identifying when the request was sent by the client. 
Applicant's specification, page 13, lines 3-10; page 15, lines 4-10; Figure 3B, item 316. 
The method of claim 1 further comprises transmitting the request to the network service. 
Applicant's specification, page 12, line 13 to page 13, line 2; Figure 3B, items 312 and 
314. 

Independent claim 13 describes a method for collecting data regarding network 
service operation. The method comprises intercepting a request sent by a client to a 
network service. Applicant's specification, page 1 1 , lines 22-23; Figure 3A, item 304. 
The method of claim 13 further comprises storing in a session timing profile information 
about the request including a name of the client, a name of the network service, and a 
request received time identifying when the request was received. Applicant's 
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specification, page 13, lines 3-10; page 15, lines 4-10; Figure 3B, item 316. The 
method of claim 13 further comprises transmitting the request to the network service. 
Applicant's specification, page 12, line 13 to page 13, line 2; Figure 3B, items 312 and 
314. 

Independent claim 25 describes a computer-readable medium (204, Figure 2) 
that stores a message handler (216, Figure 2). The computer-readable medium 
comprises logic configured to intercept messages sent by a client and directed to a 
network service. Applicant's specification, page 1 1 , lines 22-23; Figure 3A, item 304. 
The computer-readable medium of claim 25 further comprises logic configured to store 
in a session timing profile information about the message including a name of the client, 
a name of the network service, and a request sent time identifying when the request 
was sent by the client. Applicant's specification, page 13, lines 3-10; page 15, lines 4- 
10; Figure 3B, item 316. The computer-readable medium of claim 25 further comprises 
logic configured to transmit the message to the network service. Applicant's 
specification, page 12, line 13 to page 13, line 2; Figure 3B, items 312 and 314. 

Independent claim 31 describes a messaging system (100, Figure 1). The 
system comprises a first network service (104, Figures 1 and 2) comprising an 
application program interface (API) (214, Figure 2) that is configured to call a message 
handler. Applicant's specification, page 9, lines 13-16. The system of claim 31 further 
comprises a message handler (216, Figure 2) that is called by the API, the message 
handler being configured to intercept requests sent by the first network service and 
directed to a second network service (Applicant's specification, page 1 1 , lines 22-23; 
Figure 3A, item 304), to store in a session timing profile information about the request 
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including a name of the first network service, a name of the second network service, 
and a request sent time identifying when the request was sent by the first network 
service (Applicant's specification, page 13, lines 3-10; page 15, lines 4-10; Figure 3B, 
item 316), to interject information into the request including a session identification 
{Applicant's specification, page 12, lines 9-12; Figure 3A, item 308), to transmit the 
message to the second network service (Applicant's specification, page 12, line 13 to 
page 13, line 2; Figure 3B, items 312 and 314), to receive a response from the second 
network service (Applicant's specification, page 13, lines 9-14; Figure 3B, item 318), 
and to store in the session timing profile information about the response including a 
name of the second network service, a name of the first network service, and a 
response received time identifying when the response was received (Applicant's 
specification, page 19, lines 13-21; Figure 6, item 614). 

VI. Grounds of Rejection to be Reviewed on Appeal 

The following ground of rejection is to be reviewed on appeal: 

1. Claims 14 and 15 have been rejected under 35 U.S.C. § 112, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the 
subject matter which the Applicant regards as the invention. 

2. Claims 1-15 and 25-34 have been rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Kaler, etal. ("Kaler," U.S. Pub. No. 2004/0199586). 



5 



VII. Arguments 

The Appellant respectfully submits that Applicant's claims are not obvious under 
35 U.S.C. § 103, and respectfully requests that the Board of Patent Appeals reverse the 
final rejections at least for the reasons discussed below. 

A. Claim Rejections - 35 U.S.C. § 112, Second Paragraph 

Applicant notes that claims 14 and 15 have been rejected under 35 U.S.C. § 112, 
second paragraph, as being indefinite for failing to particularly point out and distinctly 
claim the subject matter which the Applicant regards as the invention. Applicant 
attempted to make minor remedial amendments to claims 14 and 15 in a Response filed 
February 1, 2008, the Examiner declined to enter those amendments because they "are 
not deemed to place the application in better form for appeal by materially reducing or 
simplifying the issues for appeal." Applicant disagrees that the amendments would not 
simplify the issues for appeal given that the amendments, if entered, would have 
overcome the rejections. Regardless, Applicant will reattempt to amend claims 14 and 
15 when prosecution returns to the Examiner after this appeal is completed. 

B. Claim Rejections - 35 U.S.C. § 103(a) 

Claims 1-15 and 25-34 have been rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Kaler, et al. ("Kaler," U.S. Pub. No. 2004/0199586). Applicant 
respectfully traverses. 
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As has been acknowledged by the Court of Appeals for the Federal Circuit, the 
U.S. Patent and Trademark Office ("USPTO") has the burden 35 U.S.C. § 103 to 
establish obviousness by showing objective teachings in the prior art or generally 
available knowledge of one of ordinary skill in the art that would lead that individual to 
the claimed invention. In re Fine, 837 F.2d 1071, 1074, 5 U.S.P.Q. 2d 1596, 1598 (Fed. 
Cir. 1988). The key to supporting an allegation of obviousness under 35 U.S.C. § 103 is 
the clear articulation of the reasons why the Examiner believes that claimed invention 
would have been obvious. See MPEP § 2141. As stated by the Supreme Court, 
"[^ejections on obviousness cannot be sustained by mere conclusory statements; 
instead, there must be some articulated reasoning with some rational underpinning to 

support the legal conclusion of obviousness." KSR v. Teleflex, 550 U.S. at , 82 

USPQ2d at 1396 (quoting In re Kahn, 441 F.3d 977, 988, 78 USPQ2d 1329, 1336 (Fed. 
Cir. 2006)). 

Applicant respectfully submits that the Examiner has not established with clearly 
articulated reasons that Applicant's claims are obvious in view of the prior art. Applicant 
discusses those claims in the following. 

1. The Kaler Reference 

Kaler discloses a system configured to route electronic messages. As described 
by Kaler, the system comprises a plurality of message processors 205-208 that 
"access" electronic messages. Kaler, paragraph 0059. By way of example, a first 
message processor 205 may by the "initiating" processor that originates the message, 
second and third message processors 206 and 207 may be "intermediary" processors 
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that route the message, and a fourth message processor 208 may be the "receiving" 
processor that is the intended destination for the message. Kaler, paragraph 0065; 
Figure 2. 

Each message processor 205-208 is configured to identify session information 
when a message is accessed. Kaler provides an explicit definition as to what he means 
by "session information" in paragraph 0041: 

In this description and the following claims, "session information" is 
defined generally to include, but is not limited to, information used to 
represent characteristics of a communication session, such as, for 
example, session identifiers, session names, session priorities, message 
sequences, message sequence names, message sequence priorities, and 
message sequence values. 

Kaler, paragraph 0041 . Accordingly, Kaler uses the term "session information" to refer 
to information that facilitates a communication session, as opposed to information that 
facilitates evaluation of the components that communicate. See also Kaler, paragraph 
0006. 



2. Applicant's Claims 
a. Claims 1-12 

Independent claim 1 provides as follows: 



1. A method for collecting data regarding network service 
operation, the method comprising: 

a client sending a request to a network service; 

intercepting the request sent by the client directed to the network 
service; 

storing in a session timing profile information about the request 
including a name of the client, a name of the network service, and a 
request sent time identifying when the request was sent by the client; and 

transmitting the request to the network service. 

As an initial matter, Kaler does not teach or suggest a "method for collecting data 
regarding network service operation" as is explicitly stated in the preamble of 
Applicant's claim 1. In fact, Kaler appears to be unconcerned with the operation of 
network services or the components that host those services. Instead, as described 
above, Kaler is concerned about facilitating communication sessions and the routing of 
messages in association with the communication sessions. Therefore, Kaler's system 
is not even configured to perform the method described by claim 1 . It is for that reason 
that Kaler does not teach or suggest several of the explicit limitations of claim 1. 
Applicant discusses those limitations in the following. 

Turning to the body of claim 1, Applicant notes that Kaler does not teach or 
suggest "intercepting" a request sent by the client and directed to a network service. In 
the final Office Action, it was argued that Kaler teaches such "intercepting" given that 
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the intermediary message processors (e.g., message processors 206 and 207 in Figure 
2) access a message being sent to another message processor (e.g., message 
processor 208 in Figure 2). In reality, the intermediary message processors do not 
"intercept" any messages. Instead, the intermediary message processors merely 
receive messages that are sent to them and forward the messages on to the next 
message processor. As described by Kaler: 

Electronic message 230 can be routed along a routing path from 
end message processor 205 to end message processor 208. Intermediary 
message processors 206 and 207 may be message processors included 
in the routing path. As illustrated by arrow 1 in FIG. 2, end message 
processor 205 can transfer electronic message 230 to intermediary 
message processor 206. Electronic message 230 can subsequently be 
transferred to intermediary message processor 207 as illustrated by arrow 
2 in FIG. 2 and arrive at end message processor 208 as illustrated by 
arrow 5 in FIG. 2. 

Kaler, paragraph 0065 (emphasis added). As is made clear in the above paragraph, the 
intermediary message processor 206 does not intercept the electronic message 230. 
Instead, the message processor 205 that created the message intentionally transfers 
the message to the intermediary message processor 206. Such an action, i.e., 
receiving a message that is intentionally transferred to you, cannot reasonably be 
considered to comprise or suggest "intercepting" the message. 

Continuing through the body of claim 1 , Kaler further does not teach or suggest 
"storing in a session timing profile information about the request including a name of the 
client, a name of the network service, and a request sent time identifying when the 
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request was sent by the client". In the final Office Action, it was alleged that Kaler 
discloses such storing in paragraphs 0016 and 0041 . This is simply not true. 

As a first matter regarding the "storing in a session timing profile . . ." limitation, 
Kaler's message processors do not store anything in a "session timing profile" because 
Kaler does not even contemplate such a profile. As described above, Kaler is not 
concerned with the operation of the message processors themselves. Therefore, Kaler 
is not concerned with the timing with which those message processors processes 
messages. Accordingly, Kaler's message processors do not have any information to 
store in a "session timing profile", as explicitly required by claim 1 . Although Kaler does 
disclose "caching" session information for use in processing subsequently received 
messages in paragraph 0016, that caching clearly is not storing information for the 
purpose of building a profile as to session timing. Instead, it appears clear that Kaler's 
message processors only temporarily maintain (as suggested by the term "cache") 
information that will be needed to process further messages within that same 
communication session. In such a case, the information would be cleared from the 
cache once the communication session is over. 

As a second matter regarding the "storing in a session timing profile . . ." 
limitation, Kaler clearly does not teach or suggest the storing of any of "a name of the 
client", "a name of the network service", or "a request sent time identifying when the 
request was sent by the client" as is also explicitly required by claim 1. Regarding 
paragraph 0016 of the Kaler reference, which was relied upon by the Examiner to 
address the "name of the client" and "name of the network service" limitations, Kaler 
states: 
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The accessing message processor determines if any session 
information should be updated. This can include adding session 
information to (e.g., in response to a query from another message 
processor), removing session information from (e.g., when session 
information is targeted only to the accessing message processor), and/or 
altering session information contained in the electronic message. Session 
information can also be retrieved from the electronic message and cached 
at the accessing message processor (or at some other accessible 
location) to facilitate the appropriate processing of subsequently received 
electronic messages. For example, cached session information can be 
utilized to determine the accessing message processor is associated with 
a communication session and/or message sequence represented in a 
subsequently received electronic message. 

Kaler, paragraph 0016. As is readily apparent from the above paragraph, Kaler is silent 
as to the names of a "client" and a "network service". Applicant identified that lack of 
disclosure in paragraph 0016 to the Examiner and requested that the Examiner 
explicitly identify the words or phrases in paragraph 0016 that comprise a disclosure of 
such names. The Examiner declined to respond. Applicant therefore respectfully 
submits that the Examiner failed to provide an "articulated reasoning with some rational 
underpinning to support the legal conclusion of obviousness" as is required by KSR v. 
Teleflex. 

With regard to the "request sent time" portion of the limitation, the Examiner 
admitted in the final Office Action that Kaler does not teach or suggest storing a request 
sent time identifying when the request was sent by the client. However, the Examiner 
argued that the storage of such information would have been "obvious and expected" 
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given that, in the Examiner's words, Kaler explicitly teaches "session information 
including time values." Final Office Action, page 4. The "time values" upon which the 
Examiner rests his obviousness case stems from Kaler's solitary identification of a 
"Delay" value in paragraph 0041 . The portion of paragraph 0041 to which the Examiner 
refers provides: 

Session information can be represented using virtually any types of values 
including, numeric values (e.g., 12, D4, 11001, etc.), characters of text 
(e.g., "c", V, "6", etc.), strings of text (e.g., "06:45:33", "Delay=132 ms", 
etc.), or user-defined values. The definition of session information is 
further defined to include signed and/or encrypted session information (or 
portions thereof), such as, for example, session information that is 
encrypted for a particular recipient. 

Kaler, paragraph 0041. In response, Applicant respectfully submits that the mere 
mathematical expression of "Delay=132 ms" does not comprise a legitimate suggestion 
that would motivate a person having ordinary skill in the art to store or log session 
timing information, such as the recited "request sent time". Again, Kaler is unconcerned 
with tracking operation of his message processors. Therefore, a person having ordinary 
skill in the art would consider the storage of session timing information when reviewing 
Kaler's disclosure. Moreover, such a person would not think to store times at which 
messages where received, or sent for that matter, in view of the cryptic phrase 
"Delay=132 ms". Not only does that phrase provide little more than an indication of a 
format of session information, the phrase raises more questions that answers them. In 
particular, it is not at all clear from the Kaler reference what that phrase means. For all 
the reader knows, the "delay" comprises a time period that a messaging processor 
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should postpone forwarding of a received message after it has been processed. 
Regardless, without more, the "Delay=132 ms" provides persons having ordinary skill in 
the art no legitimate motivation for any modification of the Kaler system. 

In view of the above, it is clear that Kaler does not in fact render claim 1 obvious. 
Applicant therefore respectfully submits that claim 1 and its dependents are allowable 
over the Kaler reference and that the rejections should be reversed. 

b. Claims 13-15 

Independent claim 13 provides as follows: 

13. A method for collecting data regarding network service 
operation, the method comprising: 

intercepting a request sent by a client to a network service; 

storing in a session timing profile information about the request 
including a name of the client, a name of the network service, and a 
request received time identifying when the request was received; and 

transmitting the request to the network service. 

Regarding claim 13, Applicant reiterates that Kaler does not teach or suggest a 
method for "collecting data regarding network service operation" for reasons described 
above in relation to claim 1. Again, Kaler is concerned about facilitating a 
communication session, not logging information as to the operation of the message 
processors that participate in that communication session. 

Second, Kaler does not teach or suggest "intercepting a request sent by a client 
to a network service" also for reasons described above in relation to claim 1 . Again, 
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Kaler's message processors merely receive messages that are intentionally sent to 
them. As such, they do not "intercept" the messages. 

Third, Kaler does not teach or suggest "storing in a session timing profile 
information about the request including a name of the client, a name of the network 
service, and a request received time identifying when the request was received". As 
described above, although Kaler describes "caching" session information for use with 
subsequently received messages of a given communication session, such caching 
clearly is not "storing" information in a "session timing profile". Furthermore, as is also 
described above, Kaler is silent as to storing, or caching for that matter, the "name of 
the client" or the "name of the network service" in paragraph 0016, which was cited by 
the Examiner. 

With further regard to the "storing in a session timing profile . . ." limitation, 
Applicant notes that Kaler does not teach or suggest storing or caching "a request 
received time identifying when the request was received" for similar reasons that Kaler 
does not teach or suggest storing "a request sent time" described in relation to claim 1 . 
As mentioned in the discussion of claim 1, Kaler is unconcerned with tracking operation 
of his message processors, such as the time they receive messages, and the cryptic 
phrase "Delay=132 ms" does not provide a legitimate motivation to a person having 
ordinary skill to store such information. 

In view of the above, it is clear that Kaler does not in fact render claim 13 
obvious. Applicant therefore respectfully submits that claim 13 and its dependents are 
allowable over the Kaler reference and that the rejections should be reversed. 
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c. Claims 25-30 

Independent claim 25 provides as follows: 

25. A computer-readable medium that stores a message 
handler, the handler comprising: 

logic configured to intercept messages sent by a client and directed 
to a network service; 

logic configured to store in a session timing profile information 
about the message including a name of the client, a name of the network 
service, and a request sent time identifying when the request was sent by 
the client; and 

logic configured to transmit the message to the network service. 

As an initial matter regarding claim 25, Applicant notes (i) that the claim is 
explicitly directed to a "message handler" and (ii) that the Examiner identified no 
components within the Kaler reference that he believes to constitute such a message 
handler. Applicant therefore respectfully submits that the Examiner has failed to state a 
prima facie case of obviousness against claim 25. Applicant further asserts that Kaler 
neither teaches or suggest such a message handler. 

Turning to the body of claim 25, Applicant submits that Kaler does not teach or 
suggest "logic configured to intercept messages sent by a client and directed to a 
network service" or "logic configured to store in a session timing profile information 
about the message including a name of the client, a name of the network service, and a 
request sent time identifying when the request was sent by the client" for reasons 
described above in relation to claim 1. Applicant therefore respectfully submits that 
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claim 25 and its dependents are allowable over the Kaler reference and that the 
rejections should be reversed. 

d. Claims 31-34 

Independent claim 31 provides as follows: 

31 . A messaging system, comprising: 

a first network service comprising an application program interface 
(API) that is configured to call a message handler; and 

a message handler that is called by the API, the message handler 
being configured to intercept requests sent by the first network service and 
directed to a second network service, to store in a session timing profile 
information about the request including a name of the first network 
service, a name of the second network service, and a request sent time 
identifying when the request was sent by the first network service, to 
interject information into the request including a session identification, to 
transmit the message to the second network service, to receive a 
response from the second network service, and to store in the session 
timing profile information about the response including a name of the 
second network service, a name of the first network service, and a 
response received time identifying when the response was received. 

Regarding claim 31, Kaler does not teach or suggest "a first network service 
comprising an application program interface (API) that is configured to call a message 
handler". Applicant notes that, although the Examiner generally alleged on page 6 of 
the final Office Action that Kaler "discloses" an API configured to call a message 
handler, the Examiner provides no citation to the Kaler reference. Applicant therefore 
respectfully submits that the Examiner has failed to provide an "articulated reasoning 
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with some rational underpinning to support the legal conclusion of obviousness" as is 
required by KSR v. Teleflex, and further that the Examiner has failed to make a prima 
facie case against claim 31 . Applicant further notes for the record that Applicant has 
reviewed the entirety of the Kaler reference and can find no disclosure of such an API. 

Kaler also does not teach or suggest a "message handler that is called by the 
API". The Examiner failed to provide a citation of where such a message handler is 
disclosed by Kaler. Therefore, the Examiner has also failed to make a prima facie case 
for that reason. Applicant notes that, if it is the Examiner's position that Kaler's 
message processors comprise a "message handlers", the Examiner cannot further rely 
on Kaler's message processors as comprising Applicant's claimed "network services". 
In other words, Kaler's message processors cannot be both the claimed "message 
handler" and "network services". Applicant further notes that, given that Kaler does not 
disclose components other than the message processors 205-208, it is clear that Kaler 
does not further disclose a separate message handler, as is explicitly required by claim 
31. 

Kaler further does not teach or suggest a message handler or another 
component that is configured to "intercept requests sent by the first network service and 
directed to a second network service" or "store in a session timing profile information 
about the request including a name of the first network service, a name of the second 
network service, and a request sent time identifying when the request was sent by the 
first network service". Regarding Kaler's message processors, those processors do not 
"intercept" messages and do not store any of "a name of the first network service", "a 
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name of the second network service", or "a request sent time" for reasons described 
above in relation to claim 1. 

As a yet another matter, Kaler does not teach or suggest a message handler or 
other component configured to "store in the session timing profile information about the 
response including a name of the second network service, a name of the first network 
service, and a response received time identifying when the response was received" for 
reasons described above in relation to claim 13. 

Applicant therefore respectfully submits that claim 31 and its dependents are 
allowable over the Kaler reference and that the rejections should be reversed. 
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VIII. Conclusion 

In summary, it is Applicant's position that Applicant's claims are patentable over 
the applied prior art references and that the rejection of these claims should be 
withdrawn. Appellant therefore respectfully requests that the Board of Appeals overturn 
the Examiner's rejection and allow Applicant's pending claims. 

Respectfully submitted, 













David R. Risk 







Registration No. 39,3< 
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Claims Appendix under 37 C.F.R. § 41.37(c)(1)(viii) 

The following are the claims that are involved in this Appeal. 

1. A method for collecting data regarding network service operation, the 
method comprising: 

a client sending a request to a network service; 

intercepting the request sent by the client directed to the network service; 

storing in a session timing profile information about the request including a name 
of the client, a name of the network service, and a request sent time identifying when 
the request was sent by the client; and 

transmitting the request to the network service. 

2. The method of claim 1, wherein intercepting the request comprises 
intercepting a request sent by a network service acting in the capacity of a client. 

3. The method of claim 1, wherein intercepting a request comprises 
intercepting a request using a message handler that is separate from and called by the 
client. 

4. The method of claim 3, wherein storing information about the request 
comprises storing information about the request using the message handler that is 
called by the client. 
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5. The method of claim 4, wherein storing information about the request 
further comprises storing information about at least one of a message type and 
substance of the request. 

6. The method of claim 1, further comprising interjecting instrumentation 
information into the request prior to transmitting the request to the network service, the 
instrumentation information including a session identification. 

7. The method of claim 6, wherein interjecting instrumentation information 
comprises interjecting instrumentation information using a message handler that is 
separate from and called by the client. 

8. The method of claim 7, wherein interjecting instrumentation information 
comprises adding instrumentation information to a header of the request. 

9. The method of claim 7, wherein interjecting instrumentation information 
further comprises interjecting at least one of a name of the client, a message type, a 
name of the network service, and a request sent time. 

10. The method of claim 1, further comprising receiving a response from the 
network service and storing data regarding the response in the session timing profile. 
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11. The method of claim 10, wherein storing data regarding the response 
comprises storing data using a message handler that is separate from and called by the 
client. 

12. The method of claim 10, wherein storing data regarding the response 
comprises storing in the session timing profile a source name of the network service, a 
destination name of the client, and a response received time identifying when the 
response was received. 

13. A method for collecting data regarding network service operation, the 
method comprising: 

intercepting a request sent by a client to a network service; 

storing in a session timing profile information about the request including a name 
of the client, a name of the network service, and a request received time identifying 
when the request was received; and 

transmitting the request to the network service. 

14. The method of claim 13, wherein intercepting a message comprises 
intercepting a message using a message handler that is separate from and called by 
the network service. 
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15. The method of claim 14, wherein storing information about the request 
further comprises storing information about at least one of a message type and 
substance of the message. 

16-24. (Canceled) 

25. A computer-readable medium that stores a message handler, the handler 
comprising: 

logic configured to intercept messages sent by a client and directed to a network 
service; 

logic configured to store in a session timing profile information about the 
message including a name of the client, a name of the network service, and a request 
sent time identifying when the request was sent by the client; and 

logic configured to transmit the message to the network service. 

26. The computer-readable medium of claim 25, wherein the logic configured 
to store information about the message comprises logic configured to store information 
about at least one of a message type and substance of the message. 

27. The computer-readable medium of claim 25, further comprising logic 
configured to interject instrumentation information into the message including a session 
identification. 
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28. The computer-readable medium of claim 27, wherein the logic configured 
to interject instrumentation information comprises logic configured to interject at least 
one of a name of the client, a message type, a name of the network service, and a 
request sent time. 

29. The computer-readable medium of claim 25, further comprising logic 
configured to receive a response from the network service and logic configured to store 
in the session timing profile data regarding the response, the data regarding the 
response comprising a source name of the network service, a destination name of the 
client, and a response received time identifying when the response was received. 

30. The computer-readable medium of claim 25, wherein the message 
handler is a simple object access protocol (SOAP) message handler. 
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31 . A messaging system, comprising: 

a first network service comprising an application program interface (API) that is 
configured to call a message handler; and 

a message handler that is called by the API, the message handler being 
configured to intercept requests sent by the first network service and directed to a 
second network service, to store in a session timing profile information about the 
request including a name of the first network service, a name of the second network 
service, and a request sent time identifying when the request was sent by the first 
network service, to interject information into the request including a session 
identification, to transmit the message to the second network service, to receive a 
response from the second network service, and to store in the session timing profile 
information about the response including a name of the second network service, a 
name of the first network service, and a response received time identifying when the 
response was received. 

32. The system of claim 31, wherein the message handler is further 
configured to, in regard to the request, store in the session timing profile information 
about at least one of a message type and substance of the message. 
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33. The system of claim 31, wherein the message handler is further 
configured to, in regard to the response, store in the session timing profile information 
about a message type and a response received time. 

34. The system of claim 31, wherein the message handler is a simple object 
access protocol (SOAP) message handler. 
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Evidence Appendix under 37 C.F.R. § 41.37fc)(1)(ix) 

There is no extrinsic evidence to be considered in this Appeal. Therefore, no 
evidence is presented in this Appendix. 
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Related Proceedings Appendix under 37 C.F.R. § 41.37(c)(1)(x) 

There are no related proceedings to be considered in this Appeal. Therefore, 
such proceedings are identified in this Appendix. 
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